Introduction
In the high-stakes world of B2B tech, it’s far too common for Sales and Sales Engineering teams to jump to action without fully understanding the “why” behind a customer’s request.
Demos are rushed. Feature requests are blindly relayed to Product. RFPs are answered with “yes” because “the customer asked for it.”
The result? A trail of misaligned expectations, wasted effort, and solutions that never quite hit the mark.
This article is a call to arms for Sales Engineers and Solution Engineers:
Slow down. Ask why. Challenge the ask. Qualify deeply. And think inside the box.
Misunderstood outcomes: the sale is not the goal
One of the most common and dangerous mistakes in Sales Engineering is confusing the vendor’s success (winning the deal) with the customer’s success (solving a business problem).
Yes, you want to close the deal. Yes, you have a quota. But the real outcome that matters—the one that keeps customers loyal, renewals flowing, and your product roadmap relevant—is the customer solving their problem.
Too often, teams anchor their strategy on our product, our demo, our roadmap, and lose sight of the fact that the customer doesn’t actually care about your product. They care about what it helps them achieve.
Fall in love with the problem, not the solution
Uri Levine, co-founder of Waze, captured this perfectly when he said:
“Fall in love with the problem, not the solution.”
It’s a mindset shift—and a powerful one. When you’re in love with the solution, you show off features. You force demos. You push a roadmap.
When you’re in love with the problem, you listen differently. You become curious. You start thinking not in terms of features, but in terms of fit.
Great Sales Engineers are obsessed with the customer’s problem—how deep it is, who it affects, what it costs, and what options exist to solve it.
That obsession is what drives relevance, trust, and long-term success.
Start with why
Simon Sinek’s now-iconic TED Talk and book Start With Why highlights a simple yet profound truth: people don’t buy what you do, they buy why you do it.
Start with why - the iconic speech by Simon SinekIn Sales Engineering, this lesson is doubly relevant. Customers don’t just need a tool—they need an outcome. A solution to a deeper business problem.
When a customer says, “Can you do feature X?”, don’t just nod and run back to Product. Ask:
- Why do you need that?
- What’s the business objective?
- Is this a workaround for something else that’s broken?
- Have you tried solving this in another way?
Understanding their motivation is what separates a demo jockey from a true trusted advisor.
Sell me this pen: it’s not about the pen
The classic challenge, “Sell me this pen,” isn’t about the pen. It’s about discovering need.
"Sell me this pen" with Jordan BelfortJordan Belfort’s version of this exercise emphasizes finding urgency and context. Instead of describing features (“it’s a sleek pen with blue ink”), you ask:
- When did you last use a pen?
- What do you use it for?
- What happens if you don’t have one when you need it?
As a Sales Engineer, apply the same rigor to technical scoping:
- Don’t just pitch features.
- Don’t just run the demo your AE asked for.
- Probe until the real need surfaces.
Box Thinking: constraint is your superpower
There’s a myth that creativity comes from thinking “outside the box.” In reality, thinking inside the box—embracing constraints—unlocks true innovation.
The best Sales Engineers don’t avoid constraints. They use them:
- “The customer only has budget for X? Let’s redesign the solution within that.”
- “They need it to run on-prem? Let’s explore how to deliver value in that context.”
- “They won’t change their workflow? Let’s integrate into it.”
This is constraint-based innovation. It leads to practical, usable, deployable solutions—not theoretical ones.
And when it comes to defining product requirements? The same rule applies:
- Constraints help narrow the scope.
- Constraints force clarity of purpose.
- Constraints reveal what really matters.
From feature requests to real requirements
Sales Engineers often act as the bridge between customers and Product. But too many SEs just pass feature requests along, word-for-word.
Let’s do better.
Ask:
- What job is the feature trying to accomplish?
- Is there a workaround today?
- How many other customers face this problem?
- Can this be solved by combining existing capabilities in a new way?
And most importantly: Is this worth building?
You don’t just pass along requests—you qualify them, shape them, and champion the ones that matter.
Conclusion: sell outcomes, not features
Being a great Sales or Solution Engineer is not about how much you know. It’s about how well you listen, translate, and frame.
- Stop doing demos just because Sales asked.
- Stop saying “yes” to RFPs without digging into context.
- Stop escalating feature requests without rethinking them.
Instead:
- Start with why.
- Fall in love with the problem, not the solution.
- Sell the outcome, not the pen.
- Use constraints as your creative advantage.
- Translate problems into valuable, scalable solutions.
Because at the end of the day:
You’re not here to sell software. You’re here to make your customer successful.
"Start with why video" by TEDx Talks "Sell me this pen" video by Oxford Union.